An RPR (Resilient Packet Ring) is a packet ring network standardized by IEEE 802.17. The RPR is a MAC layer protocol for providing access to a transmission medium in a ring configuration. The RPR can realize failure recovery of carrier class at high speed, allow effective utilization of a network band, and provide data-forwarding through the shortest path.
FIG. 14 is an explanatory diagram showing an example of a network configuration of an RPR. As shown in FIG. 14, the packet ring included in the RPR network has two ringlets 1101 and 1102 for forwarding packet in opposite directions to each other. In the packet ring, a plurality of nodes connected in a ring configuration. In FIG. 14, four nodes 1103a, 1103b, 1103c and 1103d are connected to the packet ring. An RPR MAC address is given to each node of the packet ring. Once the network is built, control packets are transmitted between the nodes. Each of the nodes collects information regarding the number of hops between the nodes, and acquires topology information of the network.
Note that a node is a device which is provided in a communication network and implements communications through the communication network. Each of the nodes provided on the packet ring is a device which implements communications with another node or a client device (a user terminal) connected to itself.
A user terminal may be connected to each node of the packet ring. In the example of FIG. 14, a user terminal 1104a is connected to the node 1103a, while a user terminal 1104b is connected to the node 1103b. 
In the following descriptions, a data packet of RPR packets to be forwarded in the RPR may be described as an RPR data packet. Similarly, a packet for control purposes of the RPR packets may be described as an RPR control packet or a control packet.
Descriptions will now be made to the RPR data packet standardized by IEEE 802.17. FIG. 15 is an explanatory diagram showing an RPR format. When a user terminal sends a packet to a node, the packet is a user data packet 211. The user data packet 211 includes a MAC address (MAC DA) 212 of the user terminal to be sent the user data packet, a MAC address (MAC SA) 213 of the user terminal sending the user data packet, transmission data 214 and an FCS (Frame Check Sequence) 215. Upon reception of the user data packet from the user terminal, the node encapsulates the user data packet so as to generate the RPR data packet 221, and sends and receives the RPR data packet 221 to and from the node. The user data packet 211 is encapsulated, and the RPR data packet 221 is stored as data 226. The RPR packet 221 includes a MAC address (RPR MAC SA) 225 of a destination node, a MAC address (RPR MAC DA) 224 of the source node, a Base Control field 223, a TTL (Time To Live) field 222 and an FCS 227. The Base Control field 223 includes information specifying a ringlet for packet forwarding and information identifying the kind of a packet, such as a control packet, etc. The TTL field 222 is used to prevent circling of the packet permanently along the ring. The format of the RPR data packet will specifically be described in non-patent document 1.
Descriptions will now be made to a transmission, reception and forwarding operations of the RPR data packet in each node of the ring.
First, descriptions will be made to the case of a unicast data packet (an RPR data packet to be unicast-transmitted). Upon reception of an RPR data packet to be forwarded through the ring, each node deletes this RPR data packet from the ring, if an RPR MAC DA of the RPR data packet is the same as an RPR MAC address of its own node. On the contrary, if the RPR MAC DA of the received RPR data packet differs from the RPR MAC address of its own node, the node decrements its TTL, and sends again the RPR data packet to the ringlet from which the packet has been received. Upon reception of a unicast data packet having sent by the node itself, the node deletes the unicast data packet from the ring. Each node deletes the RPR data packet from the ring, when its TTL value reaches “0” (zero).
For the case of a broadcast data packet (an RPR data packet to be broadcast-transmitted), each of the nodes forwards the received broadcast data packet to a next node, after decrementing the TTL value of the packet. Upon reception of the broadcast data packet sent by it self, the node sending the broadcast data packet deletes the broadcast data packet from the ring. Each of the nodes deletes the RPR packet from the ring, when the TTL value reaches “0”.
Descriptions will now be made to an RPR control packet (control packet) standardized by IEEE 802.17. Of all nodes of the RPR network, each RPR node sends and receives a control packet through a data path so as to implement autonomous operations, such as a topology discovery function, a protection function, an OAM (Operation, Administration and Maintenance) function, etc. The IEEE 802.17 specification defines the individual control packet of each of the functions (e.g. those functions described above). The control packet is forwarded between the nodes similarly to the above-described forwarding of the RPR data packet.
Descriptions will now be made to an operation for sending data from the user terminal 1104a connected to the node 1103a to the user terminal 1104b connected to the node 1103b, in the RPR network shown in FIG. 14. Each of the nodes learns the an encapsulated MAC SA 213 (see FIG. 15) of the source user terminal and a source RPR MAC SA 225 (see FIG. 15) in the received RPR data packet, in association with each other, and keeps a database (i.e. an FDB (Forwarding Database)) of the RPR MAC address, which a search key is the MAC address of the user terminal. After the user terminal 1104a sends data (a user data packet) to the ring, the node 1103a receives this user data packet. The node 1103a searches the FDB based on the search key of the MAC DA 212 (see FIG. 15) in the received user data packet, and sets a searched result as an RPR MAC DA 224 (MAC address of the source node, see FIG. 15). The node 1103a sets its MAC address as an RPR MAC SA 225 (MAC address of the source node, see FIG. 15). Then, the node encapsulates the user data packet received from the user terminal 1104a. Further, the node 1103a searches the topology database, selects a ringlet for providing the shortest path from the source node to the destination node, sets a TTL value, and sends the RPR data packet to the ring.
As a result of searching the FDB, if the node has not learned the corresponding relationship between a MAC address of the target user terminal and the RPR MAC address corresponding to this MAC address, the node 1103a implements Flooding. A broadcast address is set for the RPR MAC DA of the RPR data packet to be sent in accordance with the flooding, and the RPR data packet is received by the all nodes of the ring. As a result of the flooding, the user data packet sent by the user terminal 1104a is received by the target user terminal 1104b. Then, the user terminal 1104b returns the packet to the user terminal 1104a. At the returning of the packet, the user terminal 1104b is a source of the user data packet, while the user terminal 1104a is the destination. In addition, the node 1103 is the source of the RPR packet. Upon returning of the packet from the user terminal 1104b, the node 1103a learns the corresponding relationship between the MAC address of the user terminal 1104b and the RPR MAC address of the node 1103b. Thus, if the user terminal 1104a sends a user data packet to the user terminal 1104b again, the node 1103a searches the RPR MAC address of the node 1103b based on the MAC DA 212 included in the user data packet, as a key. The node sets a result of this search as a RPR MAC DA 224 so as to implement unicast forwarding of the packet.
Descriptions will now be made to a protection operation for the RPR with reference to FIGS. 16A to 16C. The IEEE 802.17 specification defines a steering mode and a lap mode as a protection operation at the occurrence of a failure. The steering mode is defined as a required function, while the lap mode is defined as a selective function. These steering mode and the lap mode are introduced in patent document 1.
FIG. 16A shows a network operation in a normal state. FIG. 16A shows a state wherein a packet is forwarded from a node 303a to a node 303b on a ringlet 301.
FIG. 16B shows an operation in the steering mode. As shown in FIG. 16B, when a failure point 304 occurs, each of the all nodes in the ring acquires positional information of the failure point 304. That is, nodes 303c and 303d connected to the link with the failure point 304 inform all other nodes about the positional information of the failure point 304. As a result, each node knows the position of the failure point 304. When to send a unicast packet, the source node selects a ringlet without the failure point 304 in a link to the node to be sent the RPR packet, and sends a unicast packet thereto. For example, when the node 303a sends a unicast packet to the node 303b, the node identifies the position of the failure point 304. As a result, the node changes the target ringlet to which the unicast packet is sent, from the ringlet 301 to the ringlet 302, and forwards the packet to the node 303b. When to send a broadcast packet, the node selects both of the ringlets 301 and 302, and sends a broadcast packet to each of the ringlets 301 and 302. As a result, a broadcast packet is sent to each node of the ring.
FIG. 16C shows an operation in the lap mode. In the lap mode, the source node selects the same ringlet as that in the normal state, and sends a RPR packet. For example, when the node 303a sends an RPR packet to the node 303b, it selects the ringlet 301 like in the normal state (see FIG. 16A) so as to send the RPR packet thereto. Upon reception of the RPR packet, the node 303c which is connected to the link with the failure point 304 and has detected the failure selects the ringlet 302 which differs from the ringlet 301 from which the packet has been sent, and forwards the RPR packet using this ringlet 302. That is, the node 303c forwards the RPR packet to the side where there is no failure point 304. This packet is forwarded on the ringlet 302, and is forwarded to the node 303d, which is connected to the link with the failure point 304 and has detected the failure. The node 303d also selects a ringlet which differs from the ringlet from which the packet has been sent, and forwards the RPR packet using this ringlet. As a result, the destination node 303b receives the RPR packet. To flood a broadcast packet to the ring, the source node sends a packet to an arbitrary one of the ringlets in accordance with a predetermined method, or the source node sends a broadcast packet to both ringlets and forwards the packet to a predetermined destination point given in advance in the ring in order to prevent duplication of packet forwarding in accordance with a bidirectional flooding method. Note that a cleave point represents the packet's destination point which has been set in advance in the ring in order to prevent the duplication of packet forwarding. In the case of the bidirectional flooding, the TTL is so calculated that the packet is forwarded to the all nodes while avoiding duplication of packet arrival, depending on as to whether the number of nodes in the ring is an odd number or an even number.
The descriptions have been made to the example wherein the link failure has occurred. The protection operation when a failure has occurred in the node is the same as that when a failure has occurred in the link.
The protection operation defined by the above-described IEEE 802.17 specification provide failure recovery at high speed in a span (or link) failure in the ring network and failure recovery at high speed in the communications between the nodes other than the node with the failure. However, the above specification does not define an operation for failure recovery when a failure has occurred in the connection of the client device under each RPR node (i.e. the link between the node and the client device). In the configuration shown in FIG. 14, if a failure has occurred in the link between the node and the client device, communication cannot be implemented between the node and the client device (user terminal).
Patent document 2 discloses a technique for recovering a failure in a ring LAN. According to the technique for recovering a failure in a ring LAN of Patent document 2, control nodes are duplicated. One of the duplicated control nodes is set as an active node (working node), while the other node is an spare node (backup node). The active control node has the same address as that of the spare control node.
Patent document 1: JP-A 2004-242194 (paragraphs 0004 and 0012)
Patent document 2: JP-A 4-100446 (pp. 4-5, FIG. 1)
Non-Patent document 1: “IEEE Std 802. 17-2004 PART 17: Resilient packet ring (RPR) access method & physical layer specifications”, IEEE (Institute of Electrical and Electronics Engineers, Inc), p. 211-223, “9. Frame formats”, Sep. 24, 2004